Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

lib/features/products/product_repository.dart (2)

86-96: 🚀 Performance & Scalability | 🔵 Trivial

Consider capping/paginating the liked-items query for scalability.

fetchLikedProducts loads the entire likedProducts subcollection with no limit(). For users with very large liked lists this grows unbounded read cost/latency on every page load; consider a limit() with incremental pagination as the feature scales.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@lib/features/products/product_repository.dart` around lines 86 - 96, Update
fetchLikedProducts to avoid loading the entire likedProducts subcollection in
one request by applying a bounded Firestore limit and supporting incremental
pagination with a cursor. Preserve the existing likedAt descending order and
product conversion behavior, and expose or reuse the surrounding pagination
contract so callers can request subsequent pages.

---

92-136: 🚀 Performance & Scalability | 🔵 Trivial | 🏗️ Heavy lift

Sequential per-item fetches and lost ordering for fallback-recovered products.

Two related issues in this loop:

1. For every liked document without a usable embedded snapshot, await _fetchProduct(reference.productId) (Line 114) runs sequentially inside the for loop — N missing snapshots means N serial network round trips before the batched home-feed fallback even starts.
2. Products recovered via _fetchProductsFromHomeFeed are appended in a second pass (Lines 124-130) after the main loop, so they lose their original likedAt-descending position — the final list is no longer fully ordered by like time whenever any items needed the fallback path.

♻️ Suggested restructure (parallel fetch + order-preserving assembly)

-      final products = <Product>[];
-      final missingProductIds = <String>[];
-      final seenProductIds = <String>{};
-
-      for (final likedDocument in likedSnapshot.docs) {
-        final reference = LikedProductReference.tryParse(
-          documentId: likedDocument.id,
-          data: likedDocument.data(),
-        );
-        if (reference == null) {
-          continue;
-        }
-
-        final product =
-            _productFromLikedDocument(
-              likedDocument.data(),
-              reference.productId,
-            ) ??
-            await _fetchProduct(reference.productId);
-        if (product != null) {
-          if (seenProductIds.add(product.id)) {
-            products.add(product);
-          }
-        } else {
-          missingProductIds.add(reference.productId);
-        }
-      }
-
-      final fallbackProducts = await _fetchProductsFromHomeFeed(missingProductIds);
-      for (final productId in missingProductIds) {
-        final product = fallbackProducts[productId];
-        if (product != null && seenProductIds.add(product.id)) {
-          products.add(product);
-        }
-      }
-
-      return Result.success(products);
+      final docs = likedSnapshot.docs;
+      final resolved = List<Product?>.filled(docs.length, null);
+      final pendingIndices = <int>[];
+      final pendingIds = <String>[];
+
+      for (var i = 0; i < docs.length; i++) {
+        final reference = LikedProductReference.tryParse(
+          documentId: docs[i].id,
+          data: docs[i].data(),
+        );
+        if (reference == null) continue;
+
+        final snapshotProduct = _productFromLikedDocument(docs[i].data(), reference.productId);
+        if (snapshotProduct != null) {
+          resolved[i] = snapshotProduct;
+        } else {
+          pendingIndices.add(i);
+          pendingIds.add(reference.productId);
+        }
+      }
+
+      final fetched = await Future.wait(pendingIds.map(_fetchProduct));
+      final stillMissing = <String>[];
+      for (var j = 0; j < pendingIndices.length; j++) {
+        resolved[pendingIndices[j]] = fetched[j];
+        if (fetched[j] == null) stillMissing.add(pendingIds[j]);
+      }
+
+      final fallbackProducts = await _fetchProductsFromHomeFeed(stillMissing);
+      for (var j = 0; j < pendingIndices.length; j++) {
+        final idx = pendingIndices[j];
+        resolved[idx] ??= fallbackProducts[pendingIds[j]];
+      }
+
+      final seenProductIds = <String>{};
+      final products = <Product>[
+        for (final product in resolved)
+          if (product != null && seenProductIds.add(product.id)) product,
+      ];
+
+      return Result.success(products);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@lib/features/products/product_repository.dart` around lines 92 - 136,
Refactor the liked-products assembly in the repository method containing the
shown loop to avoid awaiting _fetchProduct sequentially: collect unresolved
references and fetch them concurrently, while retaining each liked document’s
position. Then resolve fallback entries through _fetchProductsFromHomeFeed and
assemble the final products in the original likedAt-descending iteration order,
using seenProductIds for deduplication and preserving the existing Result
behavior.

lib/features/products/product_viewmodel.dart (1)

100-121: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick win

Use value equality for liked-product snapshots. _likedProductSnapshots[product.id] != product is identity-based here because Product doesn’t define ==/hashCode. Since loadLikedProducts() passes freshly fetched Product instances into cacheLikedProducts(), unchanged items still look different and notifyListeners() fires on each refresh. Compare a stable field or add value equality to Product.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@lib/features/products/product_viewmodel.dart` around lines 100 - 121, Update
cacheLikedProducts to compare liked-product snapshots by stable product values
rather than Product identity, so freshly fetched but unchanged products do not
set changed or trigger notifyListeners; use an existing stable field comparison
or implement Product value equality via ==/hashCode.

test/liked_product_reference_test.dart (1)

1-36: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Add coverage for a populated likedAt value.

All three tests omit likedAt from the input data, so _parseLikedAt's Timestamp/DateTime branches are never exercised — only the null case is covered. Since likedAt is a core part of the persisted schema this PR introduces, add a case asserting successful parsing of a real value (e.g., Timestamp.fromDate(...)).

✅ Suggested additional test

+    test('parses a populated likedAt timestamp', () {
+      final likedAt = DateTime(2026, 1, 1);
+      final reference = LikedProductReference.tryParse(
+        documentId: 'product-4',
+        data: {'productId': 'product-4', 'likedAt': Timestamp.fromDate(likedAt)},
+      );
+
+      expect(reference, isNotNull);
+      expect(reference!.likedAt, likedAt);
+    });

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@test/liked_product_reference_test.dart` around lines 1 - 36, The
LikedProductReference tests lack coverage for parsing a populated likedAt value.
Add a test in the LikedProductReference group that passes a real
Timestamp.fromDate value through tryParse, asserts the reference is created, and
verifies likedAt matches the expected parsed DateTime.

test/mvp_profile_stats_test.dart (1)

93-119: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Missing coverage for Profile → Liked Items navigation.

This test confirms the "Liked" tile renders but never taps it to verify it actually navigates to LikedItemsPage, which is the PR's core new user flow. Mirror the routing setup from test/liked_items_page_test.dart (onGenerateRoute: AppRoutes.generateRoute + navigatorKey) and assert find.byType(LikedItemsPage) after tapping the "Liked" tile.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@test/mvp_profile_stats_test.dart` around lines 93 - 119, The ProfilePage
widget test currently verifies only that the Liked shortcut renders, not that it
navigates correctly. Update the test setup around ProfilePage to mirror
liked_items_page_test.dart by configuring AppRoutes.generateRoute and the shared
navigatorKey, then tap the profileUserLiked tile and assert that LikedItemsPage
is present while preserving the existing visibility assertions.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

lib/features/products/product_repository.dart (1)

22-66: 🚀 Performance & Scalability | 🔵 Trivial

Consider supporting pagination for liked items.

Currently, fetchLikedProducts hardcodes a limit of 50 items and does not process the pagination metadata (such as nextCursor) returned by the API. Users with more than 50 liked items will only see their 50 most recent likes.

As the feature matures and user activity grows, consider updating this method to accept a cursor and returning the pagination metadata alongside the products, enabling the UI to implement infinite scrolling.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@lib/features/products/product_repository.dart` around lines 22 - 66, The
fetchLikedProducts method currently retrieves only one fixed-size page and
discards pagination metadata. Update its API and implementation to accept an
optional cursor, pass that cursor with the existing limit to
ApiEndpoints.likedProducts, and return the extracted products together with the
response’s nextCursor (using the project’s established pagination result type),
so callers can request subsequent pages.